Pour me rappeler, je m'essai aux résumés.

Prefer NRVO to RVO

* RVO = return-value optimization

MyData myFunction() {
    return MyData(); // Create and return unnamed obj
}
MyData abc = myFunction();

With RVO, the C++ standard allows the compiler to skip the creation of the temporary, treating both object instances—the one inside the function and the one assigned to the variable outside the function—as the same. This usually goes under the name of copy elision. But what is elided here is the temporary and the copy.

• NRVO = named return-value optimization

MyData myFunction() {
  MyData result;           // Declare return val in ONE place
  if (doing_something) {
    return result;       // Return same val everywhere
  }
  // Doing something else
  return result;           // Return same val everywhere
} 
MyData abc = myFunction();

Named Return Value Optimization is similar but it allows the compiler to eliminate not just rvalues (temporaries), but lvalues (local variables), too, under certain conditions.

But many compilers are actualy failing to apply NRVO with the following code:

 MyData myFunction() {
    if (doing_something)
        return MyData();     // RVO expected

    MyData result;

    // ...
    return result;           // NRVO expected
} 
MyData abc = myFunction();

So previous example has to be preferred.

Return parameters by value whenever possible

Surprisingly, don’t use "out-parameters" but prefer "return-by-value", even if it implies creating a small struct in order to return multiple values. I will check that, because it seems strange to me.

“out” parameter pointers force a modern compiler to avoid certain optimisations when calling non-inlined functions.

Prefer:

struct fractional_parts {
    int numerator;
    int denominator;
};

fractional_parts convertToFraction(double val) {
    int numerator = /*calculation */ ;
    int denominator = /*calculation */ ;
    return {numerator, denominator}; // C++11 braced initialisation -> RVO
}
auto parts = convertToFraction(val);
use(parts.nominator);
use(parts.denominator);

than:

void convertToFraction(double val, int &numerator, int &denominator) {
    numerator = /*calculation */ ;
    denominator = /*calculation */ ;
}

int numerator, denominator;
convertToFraction(val, numerator, denominator); // or was it "denominator, nominator"?
use(numerator);
use(denominator);    

Cache member-variables and reference parameters

Prefer:

template <class T> 
complex<T> &complex<T>;::operator*=(const complex<T> &a) {
   T a_real = a.real, a_imag = a.imag;
   T t_real =   real, t_imag =   imag; // t == this
   real = t_real * a_real – t_imag * a_imag;
   imag = t_real * a_imag + t_imag * a_real;
   return *this;
}

than:

template <class T> 
complex<T> &complex<T>;::operator*=(const complex<T> &a) {
   real = real * a.real – imag * a.imag;
   imag = real * a.imag + imag * a.real;
   return *this;
}

It seems the example is too simple to really understand the benefits. I do not want to make my code more complex for such a simple case... I do not like this advice.

Organise intelligently member variables

Due to the CPU caches mechanisms (blocks of 64-byte), it is propose to organise member variables in a class as follow:

• Move the most-frequently-used member-variables first
• Move the least-frequently-used member-variables last
• If variables are often used together, group them near each other
• Try to reference variables in your functions in the order they’re declared

Why not...

Gah !

# !$ references the last argument of the previous command.
mate _posts/2011/2011-04-12-terminal-strings.mdown
git add !$
tumblr !$

# Now more complex, let's copy the second argument
# !! references the last command, and :2 the second arg. 
echo foo bar baz
echo !!:2 # outputs "bar"

# Batshit crazy
# !?baz? references the last command containing baz, :0-1 grabs the two first args
echo !?baz?:0-1 # should output "echo foo"

Un nouveau service de Fog Creek : HyperDev. Ils sont fous fous, et ils savent bien rendre utiles une idée balbutiante.

cd : revenir dans le répertoire personnel
cd - : revenir dans le répertoire précédent (uniquement si vous avez exécuter un cd)

Ctrl+l : effacer l'écran
Ctrl+c : arrêt d'une commande
Ctrl+z : suspendre(mettre en pause) une commande
CTRL+t : corréction d'une erreur de frappe en inversant 2 lettres
Ctrl+a : aller au début de ligne
Ctrl+e : aller à la fin de ligne
Ctrl+s : interruption de la sortie de terminal (masquer la saisie)
Ctrl+q : annuler l'interruption de la sortie (afficher la saisie)
Ctrl+u : efface tout à gauche du curseur
Ctrl+w : efface le mot à gauche du curseur
Ctrl+k : efface le mot à droite du curseur
Ctrl+y : coller la saisie précédente
Ctrl+d : efface le caractère courant, si la ligne est vide deconnexion

Alt+b : se déplacer en avant, mot par mot dans la ligne de commande
Alt+f : se déplacer en arrière mot par mot dans la ligne de commande
Alt+d : efface le mot suivant
Alt+t : échange le mot courant avec le mot précédent
Alt+c : met en majuscule la lettre courante, tout le reste dut mot courant en minuscules, puis se deplace au mot suivant
Alt+l : met en majuscules à partir de la lettre courante jusqu'à la fin de mot, puis se deplace au mot suivant
Alt+u : met en minuscules à partir de la lettre courante jusqu'à la fin de mot, puis se deplace au mot suivant

Alt+Backspace : effacer le mot précédent (équivalent Ctrl+w)

De bons conseils pour les scripts bash.

Cette bibliothèque Javascript pour faire des graphes semble bien complète.

Je n'avais pas encore pris le temps de le lire celui là. Très clair, ça rafraichit la mémoire.

La relève à distance n'était pas indispensable : ils auraient pu mettre un site web où le client entre les données.

Et si l'opérateur pense que le client ne sera pas honnête en rentrant des chiffres à son avantage, je vois pas pourquoi, en tant que client, je considèrerais l'opérateur honnête à mon tour. Ça va dans les deux sens.

Bienvenue dans le monde réel ;-)
Pour le coup, ERDF n'a pas trop le choix, la télé-relève est une directive Européenne. Mais qu'il y ait télé-relève ou non, l'opérateur du réseau doit de toute façon compter de manière relativement sûre l'énergie, que ce soit pour la facturation (ce qui nous concerne), que pour la gestion de son réseau (ce qui le concerne). Retarder "l'allumage" d'une centrale nucléaire d'une heure parce qu'on connait plus précisément son réseau, ça n'a pas de prix ! (coucou le véhicule électrique qui se décharge sur le réseau !) La livraison d'énergie n'est pas une mince affaire.

Si le code source du linky est publié et qu'une compilation de ce dernier donne la même md5 que le firmware de mon compteur, alors je les considèrerais clean. Et je consentirais à publier un article pour le dire.

C'est intéressant ce que tu proposes là. Je pense qu'aujourd'hui, la problématique c'est surtout que les 35 millions de compteurs sachent communiquer avec le concentrateur (qui envoie les données à ERDF en CPL G3 ou en sans fil selon les cas). Quand on est à ce nombre là, et qu'on doit supporter ce système pendant plusieurs dizaines d'années, il faut que plusieurs constructeurs sachent produire Linky (ils seraient mal si le seul fournisseur faisait faillite), et que chaque compteur soit interopérable. Ce sont les enjeux principaux : que ça marche partout (grande ville, rase campagne, ...), et que ça marche avec tous les fournisseurs de compteurs Linky.
En terme de complexité et des défis à relever, ce type de projet est juste énorme !J'aime ce genre de truc.

Je ne sais pas s'il pourrait rendre accessible les sources de la partie applicative d'un compteur (faut pas rêver, l'industrie est encore bien loin d'envisager le libre, mais des sources accessibles, c'est toujours ça)... Je ne pense pas que quelqu'un chez eux aura l'idée tout seul de ce genre de chose. Si quelqu'un trouve un moyen de demander/discuter ce genre de choses avec ERDF, ça pourrait être vraiment amusant.